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f57) Abstract: A system and method are disclosed for conducting elecd^nic commerce such as a virtual purchase transaction with 
an on-line merchant. A user is provided with an intelligent token, such as a smart card containing a digital certificate. The intelligent 
® token suitably authenticates with a wallet server on a network that conducts all or portions of the transaction on behalf of the user 
n without requiring changes to the merchant's server. The wallet server interacts with a security server of a selected financial service to 
^ provide authentication of the transaction. Upon authentication, the digital wallet prefiUs forms which are transmitted to the ntierchant 
1^ who contacts the security server for validation of the forais and upon validation, completes the transaction with the user. 
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For two-letter codes and other abbreviations, refer to the "Guid- 
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SMARTCARP INTERNET AUTHORIZATION SYSTEM 



FIELD OF THE INVENTION 

The invention relates generally ' to methods and apparatus for 
conducting network transactions, and . more particularly, to systems for 
5 authenticating and conducting business over data networks such as the 
Internet. 

BACKGROUND OF THE INVENTION 

In recent years, many consumers have discovered the convenience 
and economy of purchasing goods and services electronically. A number of 
10 channels for electronic purchases (commonly called "e-purchases") are 
available, including shop-at-home television networks, call-in responses to 
television advertisements, and the like. Most recently, direct purchasing via 
the Internet has become extremely popular. 

In a typical Internet transaction, a consumer generally identifies goods 
15 and/or services for purchase by viewing an online advertisement such as a 
hypertext markup language (HTML) document provided via a World Wide 
Web (WWW) browser. Payment typically occurs in various ways. One such 
way is via a charge card number that is provided via a secure channel such 
as a secure sockets layer (SSL) connection that is established between the 
20 consumer and the merchant. 

While millions of such transactions take place every day via the 
Internet, these conventional SSL transactions often exhibit a number of 
marked disadvantages. Although SSL typically provides a secure end-to-end 
connection that prevents unscrupulous third parties from eavesdropping (e.g.. 
25 "sniffing") or othenwise obtaining a purchaser's charge card number, the 
protocol does not provide any means for ensuring that the charge card 
number itself is valid, or that the person providing the card number is legally 
authorized to do so. Because of the high incidence of fraud in Internet 
transactions, most charge card issuers consider network transactions to be 
30 "Card Not Presenf transactions subject to a higher discount rate. Stated 
another way. because of the increased risk from "Card Not Present" 
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transactions, most charge card issuers cliarge the merchant a higher rate for 
accepting card numbers via electronic means than would be charged if the 
card were physically presented to the merchant. 

To improve the security deficiencies inherent in transporting charge 
5 card numbers over unsecure networks, many have suggested the use of 
"smart cards". Smartcards typically include an integrated circuit chip having a 
microprocessor and memory for storing data directly on the card. The data 
can correspond to a cryptographic key, for example, or to an electronic purse 
that maintains an electronic value of currency. Many smart card schemes 
have been suggested In the prior art, but these typically exhibit a marked 
disadvantage in that they are non-standard and typically require the 
merchants to obtain new. proprietary software for their Web storefronts to 
accept the smart card transactions. Moreover, the administration costs 
involved with assigning and maintaining the cryptographic infomiation 
associated with smart cards have been excessive to date. 

Another standard, the Secure Electronic Transaction (SET) standard 
has been suggested to improve the security of Internet transactions through 
the use of various cryptographic techniques. Although SET does provide 
improved security over standard SSL transactions, the administration involved 
with the various public and private keys required to conduct transactions has 
limited SETs widespread acceptance. SET also requires special software for 
those merchants wishing to support SET transactions. 

Additionally, existing digital wallet technology, such as the digital wallet 
technology provided by, for example. GlobeSet, Inc.. 1250 Capital of Texas 
Highway South. Building One. Suite 300, Austin. TX, 78746. Is being more 
frequently used to provide a means for users to utilize transaction card 
products (e.g.. credit, charge, debit, smart cards, account numbers and the 
like) to pay for products and sen/ices on-line. In general, digital wallets are 
tools which store personal information (name, address, chargecard number, 
credit card number, etc.) in order to facilitate electronic commerce or other 
network interactions. The personal information can be stored on a general 
server or at a client location (PC or Smartcard) or on a hybrid of both a 
general sen/er and a client sen/er. Presently, the digital wallet general server 
is comprised of a Web server and a database sen/er which centrally houses 
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the user's personal and credit card information, shopping preferences and 
profiles of on-line merchants^ 

A digital wallet preferably performs functions such as single sign 
on/one password, automatic fomi filling of check out pages, one or two click 

5 purchasing, personalization of Websites, on-line order and delivery tracking, 
Itemized electronic receipts, and customized offers and promotions based 
upon spending patterns and opt-ins. More particularly, a one-click purchase 
activates the wallet and confinns the purchase at the same time. A two-click 
check out first activates the wallet, then the second click confirms the 

10 purchase. In use, the wallet bookmark is typically clicked by the user and an 
SSL session is established with the Wallet sen/er. A browser plug-in is 
executed and the user supplies an ID/password or smart card for 
authentication in order to gain access to the wallet data. When shopping at 
an on-line merchant, the appropriate wallet data is transfen-ed from the wallet 

15 sen/er to the merchant's Web sen/er. 

Existing systems, however, generally require that a merchant initiate 
changes to accommodate each different smart card or wallet. Accordingly, a 
new system of conducting electronic transactions is desired which would 
provide improved security with minimal overhead for users and merchants. 

20 Moreover, such a new system should integrate well with various smart cards 
and Internet wallets and other services provided by various merchants without 
requiring the merchant to make substantial changes to pemnit use of different 
systems. 

SUMMARY OF THE INVENTION 
In_an exemplary embodiment of the invention, a user is provided with a 
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smart card having a standardized protocol to make credit and debit 
transactions, such as, for example, the Blue™ from American Express™ 
smart card or the Europay MasterCard™ Visa™ (EMV) smart card. The user, 
also known as the cardmember (CM), utilizes the EMV Smartcard to interface 
with a wallet sen/er to authenticate the user with a merchant sen/er on a 
network through communications witH a security sen/er provided by a financial 
institution or credit provider such as, for example. American Express (AMEX). 
The CM purchaser conducts a virtual purchase transaction via the internet 
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through a wallet server interacting with the security server to provide 
enhanced reliability and confidence in the transaction. 

' The user logs onto the internet via a browser and selects a wallet, 

causing the establishment of a secure sockets layer linl< to the wallet server 

5 and, at about the same time, activates the client window. The wallet server 
requests the user to insert the smartcard for authentication to the server wallet 
account. With an encrypted identity certificate being set, the user then selects 
the credit provlder/nnancial institution, such as AMEX, who will be providing 
guarantee of the payment, from the provider available in the wallet. The user 

10 then logs onto the merchant server, completes shopping, goes to the 
checkout screen and clicks secure checkout. Again, the interfaces are over a 
secure sockets layer. 

Next, the wallet server completes the fonn and transmits it to the 
merchant sen/er, which uses telephone connections via a modem, direct link 

15 to a third party processor or directly to the security processor of the credit 
provider. The credit provider security processor uses the wallet interface to 
the user card to access smartcard functionality and generates a signed 
transaction. Alternatively, the connection can also be used to securely update 
functionality as required. The AMEX security processor authorizes the 

20 transaction on a "card press" basis. The merchant server then integrates the 
authorization with the wallet server completed fomi received from the wallet 
server and successfully completes the transaction, infomning the user that the 
transaction has been successfully completed. 

Thus, electronic transactions, such as purchase transactions, are 

25 conducted by receiving a transaction request from a user at a wallet server, 

issuing a challenge tqjhe user from the wallet server, receiving a response 

from the user based upon the challenge, processing the response to verify the 
transaction instrument, assembling credentials (including authorization for the 
electronic transaction), and interfacing with a security server to authenticate 

30 the transaction. The system provides the benefits of protecting the market 
and the credit provider from fraud, transaction non-imputation, an ability to 
modify parameters on-line, and providing the user with better service at a 
lower cost by reducing the costs to the merchant because the entire process 
is transparent to the merchant. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
The above and other features and advantages of the present Invention 
are hereinafter described in the following detailed description of exemplary 
embodiments to be read In conjunction with the , accompanying drawing 
5 figures, wherein like reference numerals are used to identify the same or 
similar parts or steps in the similar views, and: 

Figure 1 is a block diagrani of an exemplary embodiment of the 
transaction system of the present invention; and 

Figure 2 is a diagram of an exemplary process executed by the 
1 0 exemplary transaction system of Figure 1 . 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
The present invention may be described herein in temns of functional 
block components and various processing steps. It should be appreciated 

1 5 that such functional blocks may be realized by any number of hardware 
and/or software components configured to perfomn the specified functions. 
For example, the present invention may employ various integrated circuit 
(I.e.) components, e.g., memory elements, processing elements, logic 
elements, look-up tables, and the like, which may canry out a variety of 

20 functions under the control of one or more microprocessors or other control 
devices. Similarly, the software elements of the present invention may be 
implemented with any programming or scripting language such as C, C++, 
Java, COBOL, assembler, PERL, or the like, wnth the various algorithms being 
implemented with any combination of data structures, objects, processes, 

25 routines or other programming elements. Further, it should be noted that the 
present inve ntion may emplo y any number of conventional techniques for 
data transmission, signaling, data processing, network control, and the like. 
Still further, the invention could be used to detect or prevent security issues 
with a scripting language, such as JavaScript, VBScript or the like. For a basic 

30 introduction of cryptography, please review a text written by Bmce Schneider 
which is entitled "Applied Cryptography: Protocols, Algorithms, And Source 
Code In C," published by John Wiley & Sons (second edition, 1996), which is 
hereby incorporated by reference. 
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It should be appreciated that the particular implementations shown and 
described herein are illustrative of the invention and its best mode and are not 
' intended to othenwise limit the scope of the present invention in any way. 

Indeed, for the sake of brevity, conventional data networking, application 
5 development and other functional aspects of the systems (and components of 
the individual operating components of the systems) may not be described in 
detail herein. Furthemiore, the connecting lines shown in the various figures 
contained herein are intended to represent exemplary functional relationships 
and/or physical couplings between the various elements. It should be noted 
10 that many alternative or additional functional relationships or physical 
connections may be present in a practical electronic transaction systerii. 

To simplify the description of the exemplary embodiment , the invention 
Is described as pertaining to a system of electronic commerce, i.e., 
transactions, running over the Internet. It will be appreciated, however, that 
15 many applications of the present invention could be fomnulated. For example, 
the system could be used to authenticate users of a computer system, or to 
activate a passcode system, or any other purpose. One skilled in the art will 
appreciate that the networi< may include any system for exchanging data or 
transacting business, such as the Internet, an Intranet, an extranet. WAN, 
20 LAN. satellite communications, and/or the like. Communication between the 
parties to the transaction and the system of the present Invention is 
accomplished through any suitable commurilcatlon means, such as, for 
example, a telephone network, Intranet, Internet, point of interaction device 
(point of sale device, personal digital assistant, cellular phone, kiosk, etc.), 
25 online communications, off-line communications, wireless communications, 
and/or the like. The users may interact with the system via any input device 
such as a keyboard, mouse, kiosk, personal digital assistant, handheld 
computer (e.g.. Palm Pilot®), cellular phone and/or the like. Similarly, the 
invention could be used in conjunction with any type of personal computer, 
30 network computer, woritstation, minicomputer, mainframe, or the like running 
any operating system such as any version of Windows, Windows NT, 
Windows 2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, 
UNIX, or the like. Moreover, although the invention is frequently described 
herein as being implemented with TCP/IP communications protocols, it will be 
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readily understood that the invention could also be implemented using IPX, 
Appletalk, IP-6, NetBIOS, OSI or any number of existing or future protocols. 

' Furthennore, the user and merchant may represent individual people, 

entities, or business and while reference is made to AMEX, this is by way of 

5 example and the financial authorization entity may represent various types of 
card issuing institutions, such as banks, credit card companies, card 
sponsoring companies, or third party issuers under contract with financial 
institutions. The payment network includes existing proprietary networks that 
presently accommodate transactions for credit cards, debit cards, and other 

10 types of financial/banking cards. 

Additionally, other participants may be involved in some phases of the 
transaction, such as an intennediary settlement institution, but these 
participants are not shown. Each participant is equipped with a computing 
system to facilitate transactions. The user has a personal computer, the 

15 merchant has a computer/server, and the financial authorization entity has a 
main frame computer; however, any of the computers may be a mini- 
computer, a PC server, a network set of computers, laptops, notebooks, hand 
held computers, set-top boxes, and the like. 

The customer and merchant may represent individual people, entities, 

20 or business. Although labeled as a "bank," the bank may represent other 
types of card issuing institutions, such as credit card companies, card 
sponsoring companies, or third party issuers under contract with financial 
institutions. It is further noted that other participants may be involved in some 
phases of-the transaction ,-Such.as.an intennediary settlement institution, but 

25 these participants are not shown. 

Each participant is equipped with a computing system to facilitate 
online commerce transactions. The customer has a computing unit in the 
form of a personal computer, although other types of computing units may be 
used including laptops, notebooks, hand held computers, set-top boxes, and 

30 the like. The merchant has a computing unit implemented in the fomn of a 

computer-server, although other implementations are possible. The bank has 
a computing center shown as a main frame computer. However, the bank 
computing center may be implemented in other forms, such as a mini- 
computer, a PC server, a network set of computers, and the like. 
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The computing units are connected witii eacli other via a data 
communication networl<. The networl< is a public networl< and assumed to be 
insecure and open to eavesdroppers, in the illustrated implementation, the 
network is embodied as the internet. In this context, the computers may or 
5 may not be connected to the internet at all times. For instance, the customer 
computer may employ a modem to occasionally connect to the intemet, 
whereas the bank computing center might maintain a pemnanent connection 
to the internet. It is noted that the network may be implemented as other 
types of networks, such as an interactive television (ITV) network. 
10 The merchant computer and the bank computer are interconnected via 

a second network, refenred to as a payment network. The payment, network 
represents existing proprietary networks that presently accommodate 
transactions for credit cards, debit cards, and other types of financial/banking 
cards. The payment network is a closed network that is assumed to be 
15 secure from eavesdroppers. Examples of the payment network include the 
American Express®, VisaNet® and the Veriphone® network. 

The electronic commerce system is implemented at the customer and 
issuing bank. In an exemplary implementation, the electronic commerce 
system Is implemented as computer software modules loaded onto the 
20 customer computer and the banking computing center. The merchant 

computer does not require any additional software to participate in the online 
commerce transactions supported by the online commerce system. 

A customer account number may be, for example, a sixteen-digit credit 
card number, although each credit provider has its own numbering system, 
25 such as the fifteen-digit numbering system used by American Express. Each 
company's credit card numbers comply with that company's standardized 
format such that the company using a sixteen-digit forniat will generally use 
four spaced sets of numbers, as represented by the number "0000 0000 0000 
0000". The first five to seven digits are resen/ed for processing purposes and 
30 identify the issuing bank, card type and etc. In this example, the last sixteenth 
digit is used as a sum check for the sixteen-digit number. The intermediary 
eight-to-ten digits are used to uniquely identify the customer. 

Refen-lng now to Figure 1, a transaction system 100 typically includes 
at least one user or cardmember (CM) having a computer incorporating an 
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internet browser 110 adapted to interface with a data network. In an 
exemplary embodiment, transaction system 100 is used in electronic 

' commerce to conduct purchase transactions. It will be appreciated that 

although the transaction system described herein is an electronic commerce 

5 system, the present invention is equally applicable to various other electronic 
transaction systems. Specifically, the user system 1 10 is a purchaser or user 
which interfaces with a computer having an interface through data network 
120 to a merchant sender 130 and also to a digital wallet server 140. 

The various computer systems and servers are interconnected as 

10 appropriate by data network 120, which is any data network, such as the 
internet or other public or private data network. Other suitable networks 120 
include the public switch telephone network (PSTN), wireless networks, 
corporate or university intranets, and the like. Additionally, merchant server 
130 is coupled to a modem 150 which is In communication with a third party 

15 processor (TPP) 160 which may be, but is not necessarily included, in the 
financial authorization entity secure processor 170. TPP 160 is further 
coupled to a virtual point of sale (POS) gateway processor 1 90 which is in the 
financial authorization entity secure processor 170. Also in the secure 
processor 170, and coupled to POS gateway processor 190, is payment 

20 authorization gateway 180. Further, wallet server 140 is coupled to merchant 
server 130 and to virtual point of sale (VPOS) gateway processor 190. 

While an exemplary embodiment has been illustrated In Figure 1, it will 
be appreciated that other embodiments are possible. Thus, as also described 
-above,-components (e.g., user-110, merchant 120, and wallet server 140) 

25 may be individual computers or networi< groups of computers acting with 
similar purpose to fulfill the functions described herein. Functionality 
attributed to a single component may be distributed among one or more 
individual computers in order to fulfill the described functionality. For 
example, the wallet sender 140 may in fact be a collection of web sen/ers, 

30 application sen/ers, data base servers, and other types of servers. Also, in 
various embodiments, data bases (not shovm) and/or profile servers (not 
shown) may be connected to wallet server 140. For further information 
related to smart cards, browser functions, digital wallets and e-commerce 
transactions, see U.S. patent applications "Transaction Card", U.S. Serial No. 
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9/653,837. filed on September 1, 2000; "Method and Apparatus for 
Conducting Electronic Transactions", U.S. Serial No.: 09/652,899, filed on 
August 31. 2000; "System and Method For Authenticating A Web Page". U.S. 
Serial No. 09/656,074, filed on September 6, 2000; and, "System and Method 

5 For Profiling A Web Site", U.S. Serial No.' 09/656,061, filed on September 6, 
2000, all of which are herein incorporated by reference. 

To conduct a transaction, user 110 suitably establishes a connection 
through network 120 with a merchant 130. When a purchase is to be 
consummated, user 110 accesses wallet server 140. User 110 Is then 

10 directed by wallet server 140 to insert a Smart Card Into the system to verify 
that a Smart Card is in the user's 110 possession. At the same time, a 
graphical representation of wallet 140 appears to the user 1 10 and user 1 1 0 
is directed to select a transaction authorization entity, such as American 
Express (AMEX). The Smart Card preferably includes a digital certificate that 

15 uniquely identifies the card such that digital credentials relating to the 
transaction may be created as described hereinafter. Upon receipt of the 
Smart Card information, wallet server 140 communicates with virtual PCS 
gateway 190. Virtual gateway 190 queries payment authorization gateway 
1 80 to obtain authorization for the payment. Upon obtaining such 

20 authorization, virtual PCS gateway transmits the infomnation to wallet server 
140. Wallet server 140 then completes an authorization fomri and transmits 
the fomi to merchant server 1 30. 

Upon receipt of the authorization fomn, merchant server via modem 
1 50 communicates with third party processor 160, which in tum 

25 communicates with virtual POS gateway 1 90, again querying payment 

authorization gateway 180. Again, virtual POS gateway 190 communicates 
through third party processor 160 via modem 150 to merchant server 130. 
authenticating the completed fomi. Once completed, merchant server 130 
authorizes the transaction and the transaction is completed, and the user 110 

30 is notified. 

Referring also to Figure 2, the flowchart shows an exemplary 
sequence of events involved in the on-line virtual transaction. As shown at 
step (210), a virtual transaction purchase by a customer is begun on-line, with 
a customer communicating with a vendor. At the completion of shopping, the 
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customer or user 1 1 0 initiates a secure clieckout procedure as shown in step 
(220), opening the wallet and interfacing a Smart Card with the wallet server 
1 40, including selecting the credit supplier. The wallet server 140 interfaces 
at step (220) with a security server to authenticate the transaction. In step 

5 (240), the wallet server 140 receives transactional authentication, completes 
an authorization form for the transaction and transmits the fornn to the 
merchant server 130. In step (250), the merchant server queries the security 
server for credit supplier authentication of the authorization form. Based on 
the information supplied by the credit supplier, and in conjunction with the 
10 authentication above discussed in the previous steps, the credit supplier 

authenticates the authorization form based on the information from the Smart 
Card provided through the wallet server and transmits an authentication to the 
merchant server 130. , Upon receipt of the authorization fomn, the merchant 
completes the virtual transaction/purchase, informing the customer and 

15 debiting the customer's account. 

Because the Smart Card as above-described contains identifying 
infonnation that is unique to a particular card, the purchase transaction 
conducted with the Smart Card is more secure than a transaction conducted 
with an ordinary charge or credit card. Accordingly, a discount rate may be 

20 justified for the secure transaction, which may be processed by the card 
issuer as a "card present" transaction. Additionally, if the transaction is a 
"card presenf transaction, risk of fraud may be transferred from the merchant 
to the card issuer. 

- Thus, the present invention is directed to a system and method for 

25 permitting the authentication of a virtual on-line transaction where a user, by 
the use of a Smart Card and a wallet sen/er, may have on-line virtual 
transactions authenticated to a merchant using various Smart Cards and 
credit providers while minimizing changes to the merchant's sen/er to 
accommodate a number of different types of systems. 

30 Accordingly, con-esponding structures, acts, and equivalents of all 

elements in the claims below are intended to include any stmctural material or 
acts for performing the functions in combination with other elements as 
specifically claimed. The scope of the invention should be detemiined by the 
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a Mowed claims and their legal equivalents, rather than by the examples given 
above. 
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CLAIMS 

' What is claimed is: 

I 

1 1 . A method for conducting a transaction, the method comprising: 

2 a. receiving a request to authenticate a transaction from a user at a 

3 server; 

4 b. requiring the user to provide an instrument for verification; 

5 c. receiving an instrument input response from the user based 

6 upon said requirement; 

7 d. processing said instrument input as an input to a security 

8 processor; 

9 e. assembling forms for the transaction, said fomns comprising said 
1 0 security processor authorization of said input to said security processor; 

^ ^ f . providing said fomis incident to said transaction and sending a 

1 2 request to said security processor for a second authorization of said forms; 

13 and 

14 g, validating said transaction with said second authorization of said 

1 5 fonns received from said security processor. 



2. The method of Claim 1 further directed to providing such transaction 
validation for different combinations of instmments and security processors 
without requiring changes to transaction processing by said merchant. 

3. The method of Claim 1 , wherein the transaction is an electronic 
purchas e transaction . 

4. The method of Claim 3, wherein the electronic purchase transaction is 
conducted using a digital wallet. 



The method of Claim 1, wherein the instrument is a smart card. 
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1 6. A method for providing secure virtual transactions between a user and 

2 a an on-line merchant without requiring changes at the merchants location, 

3 the method comprising: 

4 a. developing a first query for transmission to a credit provider; 

5 b. receiving a response from said credit provider and transmitting 

6 same to said merchant; 

7 c. said merchant querying' said credit provider for authentication of 

8 said credit provider response; and 

9 d. completing said virtual transaction using authorization from said 
10 credit provider. 

7. The method of Claim 6 wherein said first query is developed by 
opening a wallet and inputting infomiation from a smart card. 

8. The method of Claim 6, further comprising developing a fomn from said 
response from said credit provider and transmitting said fomn to said 
merchant. 

9. -^The method of Claim 8, wherein said merchant requests authentication 
of said fonn from said credit provider. 

1 0. The method of Claim 6, wherein said credit provider is selected by said 
user from a group of credit providers. 

1 1 . The method of Claim 9, wherein said credit provider is selected by said 
user from a group of credit providers.. 

1 12. A method for conducting a transaction, the method comprising: 

2 a. receiving a request to authenticate a transaction with a 

3 merchant from a server; 

4 b. requiring an instrument for providing verification ; 

5 c. receiving an instrument input response based upon said 

6 requirement; 
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7 . d. processing said instrument input as an input to a security 

8 processor; 

' 9 e. assembling forms for the transaction, said forms comprising said 

10 security processor authorization of said input to said security processor. 

f. providing said forms incident to said merchant; 
^2 g. said merchant processing said fomis and sending a request to 

13 said security processor for a second authorization of said forms; and 
^4 . h. validating said transaction with said second authorization of said 

15 forms received from said security processor. 

1 3. The method of Claim 12, further directed to providing such trarisaGtion 
validation for different combinations of instruments and security processors 
without requiring changes to transaction processing by said merchant. 

14. The method of Claim 12, wherein the transaction is an electronic 
purchase transaction. 

1 5. The method of Claim 14, wherein the electronic purclnase transaction is 
conducted using a digital wallet. 

16. The method of Claim 12. wherein the instrument is a smart card. 

1 17. A method for conducting a transaction, the method comprising: 

2 a. receiving a request to authenticate a transaction at a server; 

3 b. requiring an instrument for verification of said request; 

4 c. — receiving an instrument input response based upon said 

5 requirement; 

6 d. processing said instrument input as an input to a security 

7 processor; 

8 e. assembling fornis for the transaction, said forms comprising said 

9 security processor authorization of said input to said security processor; 
^0 f. providing said forms for authorization; 

^ ^ g. processing said forms and sending a request to said security 

12 processor for a second authorization of said fomns; and 
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^3 h. validating said transaction with said second authorization of said 

14 forms received from said security processor. 

18. The method of Claim 1 7, further directed to providing such transaction 
validation for different combinations of instalments and security processors 
without requiring changes to transaction processing by said merchant. 

19. The method of Claim 1 7, wherein the transaction is an electronic 
purchase transaction.' 

20. The method of Claim 1 9, wherein the electronic purchase transaction is 
conducted using a digital wallet. 

21 . The method of Claim 17, wherein the instrument is a smart card. 

1 22. A method for conducting a transaction, the method comprising: 

2 a. receiving a request to authenticate a transaction with a 

3 merchant from a user at a server; 

4 b. requiring the user to provide an instrument for verification; 

5 c. receiving an instrument input response from the user based 

6 upon said requirement; 

7 d. processing said instrument input as an input to a security 

8 processor; 

9 e. assembling forms for the transaction, said forms comprising said 
1 0 security processor authorization of said input to said security processor; 

^ ^ f . providing said fomis to said merchant; 

^2 g. said merchant processing said forms and sending a request to 
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14 



said security processor for a second authorization of said forms; and 

h. validating said transaction with said second authorization of said 



1 5 forms received from said security processor. 



23. The method of Claim 22, further directed to providing such transaction 
validation for different combinations of instruments and security processors 
without requiring changes to transaction processing by said merchant. 
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24. The method of Claim 22, wherein the transaction is an electronic 
purchase transaction. 

25. The method of Claim 24, wherein the electronic purchase transaction is 
conducted using a digital wallet, 

26. ' The method of Claim 22, wherein the instrument is a smart card. 



1 27. A transaction system, comprising: 

2 a. a data network, including at least one instrument and operative 

3 to permit initiation of a transaction; 

4 b. an authorization server coupled to receive said Initiation of said 

5 transaction as an input and transmit same to a security server; 

6 c. said security server operative to receive said input from said 

7 authorization server and generate and transmit an authorization to said 

8 authorization server; 

9 d. said authorization server coupled to receive said authorization 

10 from said security server and operative to generate and transmit an 

1 1 authorization fomi; and 

12 e. an interface coupled to said security server and operative to 

13 permit validation of said fomri and complete a secure on-line virtual 

14 transaction. 



28. The transaction system of Claim 27, further operative to provide said 
validation for different combinations of instmments and security processors. 

29. The transaction system of Claim 27, wherein said authorization sen/er 
is an electronic purchase server. 

30. The transaction system of Claim 29, wherein said electronic purchase 
server is coupled to a digital wallet and operative to validate said transaction 
input transmitted to said security server. 
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1 31. A transaction system, comprising: 

2 a. , a data networl< operative to permit a user to initiate a 

3 transaction; 

4 b. an authorization server coupled to receive an input from said 

5 user and transmit same to a security server; 

6 c. said security server coupled to receive said input from said 

7 authorization server and operative to generate and transmit an authorization 

8 to said authorization sen/er; 

9 d. said authorization server coupled to receive said authorization- 

10 from said security server and operative to generate and transmit an 

11 authorization form; and 

^2 e. an interface coupled to said security server and operative to 

1 3 permit validation of said fomi and complete a secure on-line virtual transaction 

14 with said user. 

32. The transaction system of Claim 31 , further operative to provide said 
form validation for different combinations of instruments and security 
processors. 

33. The transaction system of Claim 31 , wherein said authorization server 
is an electronic purchase server. 

34. The transaction system of claim 33, wherein said electronic purchase 
server is coupled to a digital wallet and operative to validate said user input 
transmitted to said security server. 



1 35. A transaction system, comprising: 

2 a. a data networi< operative to permit initiation of a transaction with 

3 a merchant; 

4 b. an authorization sen/er coupled to receive said transaction 

5 initiation as an input and transmit same to a security server; 

6 c. said security sen/er coupled to receive said input from said 

7 authorization server and operative to generate and transmit an authorization 

8 to said authorization server; 



1 
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d. said authorization server coupled to receive said authorization 
from said security server and operative to generate and transmit an 
11 authorization fonn; and 

^2 e. an interface coupled to said security server and operative to 

permit validation of said form and complete a secure on-line virtual transaction 



13 



14 with said user. 

36. The transaction system of Claim 35, further operative to provide said 
validation for different combinations of instruments and security processors. 

37. The transaction system of Claim 35. wherein said authorization server 
is an electronic purchase server. 

38. The transaction system of Claim 37. wherein said electronic purchase 
server is coupled to a digital wallet and operative to validate said transaction 
input transmitted to said security server. 
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SYSTEMS AND METHODS FOR AUTHORIZING A TRANSACTION CARD 

BACKGROUND OF THE INVENTION 

1 Tfir.hnical Field 

The present invention relates, generally, to transaction card fraud reduction 
5 systems and methods and. more particularly, to verifying that a consunier is in possession 
of a transaction card and/or is the true card owner during a purchase transaction. 

2. f^i]q\^fjrnund Information 

Transaction cards such as, for example, credit cards, debit cards, bank cards, 
charge cards, smart cards and the like, have become increasingly popular for purchasing 

10 goods and services and for conducting other transactions. A transaction card typically 
includes information related ito the issuer's name and logo, an account number, an 
expiration date and the cardholder's name. The cards may also have other infomiation. 
serial number and/or the like printed on the card to represent other infomiation about the 
transaction card or about the card member such as. for example, a group number, a 

15 promotion number, a card type number, a plastic issuance number and/or the like. 
Certain information is often embossed on the card with raised print, thereby allowing the 
information to be imprinted on a charge slip: however, the infomiation that is unembossed 
(flat) would not be imprinted onto the charge slip. For many transaction cards, the 
information printed on the card is also contained within a magnetic stripe, a bar code 

20 and/or an integrated circuit (microchip) for automatic downloading/reading by a card 
reader. 

Many card transactions are commenced by inserting, or sliding a card through, a 
card reader which automatically downloads the card inf ormation, the reby allowing the 
infoniiationTo be used during the authorization process without the need for manual input 
25 or review of the card information. However, because of the substantial increase in 
fraudulent use and theft of transaction cards, the use of the card information is often 
supplemented by various fraud prevention techniques, such as requiring a signature to 
verify the consumer's agreement to the transaction or the entry of a PIN number to verify 
the consumer's authority to use the transaction card. Additionally, certain card issuers. 



-1 - 



PCTAJS99/25423 

WO 00/25262 

such as banks, incorporate the consumer's picture onto the face of the transaction card 
to give the merchant an additional verification procedure. 

While the use of a signature. PIN or picture is effective for fraud reduction when the 
cardholder presents a card to a merchant, these options are not as effective, and may not 

5 be available, for other transactions. Particularly, transactions which do not require face- 
to-face contact between a consumer and merchant, such as the use of a transaction card 
to purchase items through the Intemet or over the telephone (e.g., mall order). Moreover, 
many transactions may be alternatively completed without using the physical transaction 
card. For example, a consumer or merchant may simply key in the transaction card 

10 number into the keypad of a POS device or the keypad on an ATM. 

When conducting Intemet, telephone or keypad transactions, a cardholder nnay 
only need to provide a card account number and expiration date to allow the merchant 
to charge a particular account and verify that the transaction card is valid. Other 
verification infomiation. such as a PIN number, is usually not disclosed because the PIN 

15 is typically memorized by the cardholder and never disclosed to anyone. Because 
merchants often only request limited information to conduct a transaction over the Intemet 
or the telephone, an increased potential for fraud exists due to the increased availability 
of this general information. In other words, regardless of a consumer's possession of the 
physical transaction card, a consumer can still fraudulently obtain and provide this general 

20 information. 

Particularly, cardholders often provide a transaction card number to telemarketers, 
merchants, bank tellers and Intemet sites, thereby allowing a merchant or clerk to retain 
the credit card number and associated information for later fraudulent use. Moreover, a 
person may overhear a transaction card number being disclosed over the telephone or, 

25 with the increase of mailbox thefts, a person may obtain a credit card number from a 
billing statement or promotional literature. Furthermore, advanced computer operators 
are able to intercept transaction card numbers which are transmitted over modems and/or 
the Intemet. Accordingly, when a merchant simply requests a credit card number from 
a consumer, it is difficult for the merchant to ensure that the consumer placing the order 

30 has the transaction card in his or her possession and/or is the true cardmember. rather 
than using a stolen account number. 
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As stated above, the use of PIN numbers are typically limited to face-to-face or 
ATM transactions wherein the consumer personally enters a PIN into a keypad and the 
merchant does not need to have knowledge of the PIN. In non face-to-face transactions, 
the PIN would need to be disclosed to the merchant. However, due to security concerns. 

5 consumers prefer to not disclose their private PIN number to merchants and especially 
prefer to not disclose the PIN number over a telephone or through the Internet. 
Particularly, a PIN number is directly associated with the account number, and as such, 
may provide increased access to a transaction card account during a fraudulent 
transaction. Accordingly, a system is needed which allows the consumer to disclose a 

10 security number which is associated with the account number, but does, not allow 
automatic access to the account. 

brieIf summary of the invention 

Due to security concerns during non face-to-face commercial transactions, 
consumers prefer to not disclose their private PIN number to merchants and especially 
1 5 prefer to not disclose the PIN numbers over a telephone or through the Internet. Instead 
of a PIN which is associated with an account and provides access to an account, a card 
identification code, which is located on the card but does not provide automatic access 
to an account, is used to verify that the consumer currently possesses the transaction 
card at the time of purchase and/or is the true card owner. 
20 Along with the account number, a transaction card includes a non-embossed four- 

digit or three-digit number, called a card identification code. During creation of a 
transaction card, a five-digit identification code is calculated from the account number, 
four-digit or three-digit identification code and the expiration date based upon a 
predetermined algorithm. A four-digit identification code is printed on the front of the card. 
25 an associated five-digit identification code is entered into the magnetic stripe and an 
associated three-digit identification code is printed in the signature panel. An embossing 
file of account numbers including associated identification codes is created and loaded 
into the account database. At the time of authorization, the four-digit number on the-front 
of the card and the account number are manually keyed into a PCS device and sent to 
30 an authorization system. The four-digit number is matched to the four-digit number on file 
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for that transaction card. If the four-digit numbers match, and other authorization 
parameters are satisfied, the transaction card is authorized. 

Alternatively, when the card is swiped through a POS device, the five-digit number 
previously entered into the magnetic stripe, along with other information, is automatically 
5 transmitted to the authorization system. The five-digit number is decomposed using a 
mathematical algorithm, and the resulting three-digit and/or four-digit numbers are 
matched against the database record (which includes the originally assigned three or four- 
digit identification codes for the account number). If the respective three or four-digit 
numbers match, and other authorization parameters are satisfied, the transaction card is 
10 authorized. 

Thus, the entry of an additional identification code helps verify that the consumer 
curently possesses the transaction card at the time of purchase or is the taie card owner, 
rather than simply using a stolen account number. Accordingly, requiring entry of an 
identification code along with the account number provides an effective deterrent to 
1 5 fraudulent use of the account number. For example, systems and methods in accordance 
with the present invention at certain tested locations have provided fraud reduction of 
approximately 78%. 

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS 
The subject invention will hereinafter be described in conjunction with the 
20 appended drawing figures, wherein like numerals denote like elements, and: 

Figure 1 is an exemplary flow diagram of the card creation and identification code 

creation process; — — 

Figure 2a is a front view of an exemplary transaction card showing an account 

-Humber and-card identification code; 

25 Figure 2b is a rear view of an exemplary transaction card showing magnetic strip 

and card identification code; 

Figure 3 is an exemplary schematic diagram of a simplified transaction card 

authorization system; 
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Figure 4 is an exemplary schematic diagram of an authorization database with 
associated identification codes in accordance with an embodiment of the present 
invention; and, 

Figure 5 is an exemplary flow diagram of the authorization process. 

5 DETAILED DESCRIPTION OF THE INVENTION 

To reduce fraud when conducting commercial transactions (i.e.. the purchase of 
goods and services) using a transaction card 10. the present system requests entry of an 
additional number to help verify that the consumer has possession of the transaction card 
at the time of purchase or is the true card owner, rather than simply using a stolen 
10 account code. Wherein a PIN number is typically memorized and not written down, the 
present number, called a card identification code 14. 15 and 16. is preferably printed on 
or encoded in transaction c^rd 10. Due to security concerns during non face-to-face 
transactions, consumers preferto not disclose their private PIN number to merchants and 
especially prefer to not disclose the PI N number over a telephone or through the Internet. 
1 5 Instead of a PIN which is associated with an account and provides access to an account, 
a card identification code 14. 15 and 16. which does not provide automatic access to an 
account, is used to help verify that the consumer currently possesses the transaction card 
at the time of purchase and/or Is the true card owner. 

With momentary reference to Figure 2a. in accordance with the present invention. 
20 a transaction card 10 includes any device suitably configured to display an account code 
12 and a card identification code 14. In a preferred embodiment, the transaction card is 
a credit card, charge card, debit card, smart card, bank card and/or the like. Transaction 
card 10 preferably includes infomiation for conducting a transaction. In a preferred 
-embodimentT-the-frontfaceof-transaction_card_1.0 includes an account code 12 and a card 
25 identification code 14 located above account code 12. Account code 12 includes any 
number of characters (n characters) comprising any combination of numbers, letters, 
symbols or other indicia which are suitably configured to identify a transaction account. 
,n a preferred embodiment, account code 12 is a 15-digrt number which identifies an 
account code, including a roufing number or other similar transaction numbers. 
30 corresponding to the card owner. One of ordinary skill in the art will appreciate that 
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account code 12 may be associated with an individual account, a corporate account, an 
organization account, or any othei- entity and the account may represent a charge 
account, a credit account, a debit account, an electronic purse account, or any other 
financial account. 

5 Card identification codes 14. 15 and 16 include any number of characters (n 

characters) comprising any combination of numbers, symbols, letters, or other indicia 
suitably configured to provide verification that the consumer has an actual card in 
possession at the time of purchase and/or is the true card owner, rather than simply using 
a stolen account code. In a prefen-ed embodiment, card identification code 14 is printed 
10 on or encoded in transaction card 10. Card identification code 14 may be located on 
either side of the card, encoded into a medium on the card and may be embossed (raised 
lettering) or unembossed (flat) into the plane of the card. In a particularly preferred 
embodiment, card identification code 14 is located on the front face of transaction card 
10 on the same side as. and above, account code 12. Moreover, card identification code 
15 14 is preferably a four-digit, unembossed (flat) number printed within the plane of the 
card. One skilled in the art will appreciate that, along with other card member infomiation. 
card identification codes 14, 15 or 16 may be initially printed on many transaction cards 
10 before, during or after account code 12 is printed on transaction card 10. In a 
preferred embodiment, card identification codes 14 or 15 are logically related to card 
20 identification code 16. 

After a consumer is approved for a transaction card, an account code 12, a four- 
digit identification code 14 and/or a three digit code 1 5. an expiration date 13 and other 
information are associated with the consumer's name in an account database 30 (see 
Figures 2a and 3). With reference to Figures 1 and 3. account code 12. a four-digit 
25-identification.code 14 (or a three-digit identification code 15). an expiration date 13 and 
other information from account database 30 are preferably transmitted to a card creation 
system 32 (step 38). In a pretended embodiment, at the time of creating transaction card 
10 for the consumer in accordance with the present invention, a five-digit identification 
code 16 is suitably calculated from account code 12. four-digit identification code -14 or 
30 three-digit identification code 15 and expiration date 13 based upon a predetermined 
algorithm (step 40). Five-digit identification code 16 is preferably calculated and encoded 
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, into the magnetic stripe because five-digit identification code 16 provides additional 
security by not being disclosed on the face of the card (only four-digit code 14 or three- 

digit code 1 5 are visible). 

After determining identification codes 14. 15 and 16. transaction card 10 is 

5 preferably created with an embossed account code 12, embossed expiration date 13. 
embossed consumer's name 11 and non-embossed card identification codes 14. 15 and 
16 (step 42). Particularly, in a preferred embodiment, a four-digit identification code 14 
is printed (non-embossed) on the front of card 10 above account code 12. an associated 
five-digit identification code 16 is encoded into the magnetic stripe and an associated 
10 three-digit identification code 15 is printed in the signature panel. One skilled in the art 
will appreciate that any one of the aforementioned cartl identification codes 14. 15 and 
16 may exist throughout this process alone or in any combination with the other card 
identification codes. For exa'mple. only identification code 14 may appear on the front of 
the card without any codes on the back of the card or In the magnetic stripe. Moreover. 

15 identification codes 14. 15 and 16 may comprise any number of digits, symbols, 
characters, letters and/or the like and may be located in any location and in any medium 
on card 1 0. For example, an identification code may be encoded into an integrated circuit 

in a smart card embodiment. 

Upon printing of transaction cards 10. an embossing file 34 including card 
20 identification codes 14. 15 and 16 is created (step 44). Embossing file 34 with associated 

identification codes 14. 15 and 16 is next uploaded into account database 30 (step 46). 

in a preferred embodiment, authorization server 26 communicates with, and analyzes the 

data within, account database 30 (step 48). Alternatively, the use of a Hardware Security 

Module allows embossing file 34 to provide a simplified, more direct transmission of 
25 -embossing-information_to._account database 30 without the need for maintenance 

uploads. In a particularly preferred embodiment, as shown in Figure 4. identification 

codes are stored in a look-up table within account database 30. 

Referring to Figure 3. an exemplary authorization system 20. account database 30 

and card creation system 32 is shown. Authorization system 20 is-any authorization 
30 system suitably configured to authorize a transaction card and notify an input device 22 

of the authorization status. One skilled in the art will appreciate that authorization system 
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20 can be an existing authorization system, such as the Central Authorization System 
used by American Express, which is re-programed or re-configured to preform the 
functions of the present invention or is a system , specially configured to preform the 
functions of the present invention. In a preferred embodiment, authorization system 20 
5 includes input device 22. network 24 and authorization server 26. Input device 22 is any 
device suitably configured to accept transaction information and transmit the infonnation 
for approval. In a preferred embodiment, input device 22 is a telephone, computer, point- 
of-sale terminal, ATM and/or the lil^e. Input device 22 preferably communicates with 
network 24, wherein network 24 is any device or software suitably configured to transmit 
10 information. In a prefen-ed embodiment, network 24 is a modem, a PSTN, an Intemet, 
an Intranet, a direct link, or any combination thereof. 

With continued reference to Figure 3, network 24 provides a communication link 
between input device 22 and authorization sen/er 26. Authorization sen/er 26 is any 
device suitably configured to authorize a transaction arid/or transaction card and notify 
15 input device 22 of the authorization status. In a prefenred embodiment, authorization 
server 26 is a centralized authorization system including transaction account codes. One 
skilled in the art will appreciate that authorization sen/er 26 can be a centralized database 
providing authorization infomnation to various input devices 22. Moreover, one skilled in 
the art will appreciate that authorization server 26 may include any combination of 
20 components, software, servers and computers suitably configured to not only authorize 
transactions and/or transaction cards, but also to provide additional transaction support 
such as report generation and promotional programs. Authorization sen/er 26 is 
preferably in communication with, and interrogates, account database 30. One skilled in 
the art will appreciate that account database 30 can be a separate component, integrated 
-25-into-authorization sen/er 26 or simply-software within authorization sen/er 26 or within 
input device 22. In a preferred embodiment, account database 30 includes a look-up 
table (see Figure 4), thereby allowing verification of the association between account 
codes 12 and identification codes 14, 15 and 16. 

Referring to Figure 5, when a consumer uses transactiomcard-10, a clerk, sales 
30 representative, merchant, consumer or other authorized person inputs account code 1 2 
and card identification code 14, 15 or 16. along with any other transaction information 
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• such as purchase amount, etc., into input device 22 (step 50). In one embodiment, card 
identification code 14 or 15 is manually keyed into input device 22. The keyed infomnation 
is' sent via network 24 to authorization server 26 (step 51). Authorization server 26 
suitably determines if the data was keyed in or swiped through input device 22 (step 52). 

5 In a preferred embodiment, to help detemnine If the data was keyed or swiped, the keyed 
data includes different formatting, uses different communication lines, different number 
of digits in the identification code and/or different header information than infomiation read 

from the magnetic stripe. 

After authorization server 26 determines that the infonnation is manually keyed 
10 information, authorization server 26 suitably interrogates account database 30 to 
determine if the keyed identification code 14 or 15 matches the respective identification 
number on file for that transaction card (step 54). If the respective identification codes 14 
or 15 match, the authorization process proceeds to determine if other authorization 
parameters are satisfied (step 58). If the respective identification codes 14 or 15 do not 
1 5 match, the transaction is denied and an "invalid Card ID" message is transmitted to the 
input device 22 (step 60). In an alternative embodiment, if the identification numbers do 
not correspond, authorization server 26 preferably prompts input device 22 to re-enter the 
card identification code and the process is repeated. If the numbers do not correspond 
again, transaction card 10 is denied. 
20 When the card is swiped through a POS device 22. the five-digit number previously 

entered into the magnetic stripe, along with other infomiation, is automatically transmitted 
to authorization sen/er 26. Authorization sen/er 26 suitably detemiines that the data 
originated from a magnetic stripe (step 52) by various methods such as, for example, data 
fomiat. communication lines from which the data was sent, header infomiation and/or the 
25 -number-of-digits in the identification code. Authorization server 26 preferably 
decomposes the five-digit identification code 16 into a four-digit number using a 
predetermined mathematical algorithm (step 56). In a prefen-ed embodiment, this 
algorithm is the inverse of the algorithm set forth above used to create the five-digit 
identificafion code 16. Altematively. account database 30 includes" five-digit identification 
30 codes 16 for each account code 12. thereby eliminating the need to transfomi the five- 
digit code 16 to a four-digit code 14. The algorithm is optimally a robust and secure 
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algorithm which conforms to the Data Encryption Standard. Similar to above, 
authorization server 26 then suitably interrogates account database 30 to detemiine if the 
derived four-digit number 14 matches the four-digit number on file for that transaction card 
(step 54). If the four-digit numbers match, the authorization process proceeds to 
5 determine if other authorization parameters are satisfied (step 58). If the four-digit 
numbers do not match, the transaction is denied and an "invalid Card ID" message is 
transmitted to the input device 22 (step 60). In an alternative embodiment, if the numbers 
do not correspond, authorization sen/er 26 preferably prompts input device 22 to re-svy^ipe 
the card identification code 16 and the process is repeated. If the numbers do not 
1 0 correspond again, transaction card 10 is denied. 

In a further altemafive embodiment, the incorporation of card identification code 14 
into a particular authorization process is optional depending on the type of transaction 
card 10 or account code 12 used for the financial transaction. In other words, when 
authorizing a transaction, the same authorization system 20 may not require a card 
1 5 identification code 14 for particular account codes 12. For example, certain consunners 
may be enrolled in a promotional program which includes a cardless account without a 
card identification code 14. As such, while other verification nneans typically exist, 
authorization server 26 may not require entry of an identification code or account 
database 30 may include any suitable automatic authorization for certain ranges of 
20 account codes 12. regardless of entry of a card identification code 14. 

In a preferred embodiment, account codes 12 are subject to periodic update as 
new card promotions or new accounts are opened. For security reasons, card 
identification codes 14. 15 or 16 are preferably only retained in authorization server 26 
until authorization or rejection is received by input device 22. Moreover, in a preferred 
-25-embodiment. card identification codes TV15 or 16 are not pemnanently stored in the input 
device 22 or the authorization seiver 26 and are not printed on documents (i.e.. receipts. 

tickets, itineraries, etc.). 

Although the invention has been described herein in conjunction with the appended 
drawings, those skilled in the art will appreciate that the scopeof^he invention is not so 
30 limited. I^odifications in the selection, design and arrangement of various components 
and steps discussed herein may be made without departing from the scope of the 
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invention as set forth In the claims. Moreover, the present invention may be described 
herein In terms of functional block components and various processing steps, it should 
be appreciated that such functional bloclcs may be realized by any number of hardware 
components configured to perfomi the specified function. For example, the present 
5 invention may employ various integrated circuit components, e.g.. memory elements, 
digital signal processing elements, look-up tables, and the like, v^hich may cany out a 
variety of functions under the control of one or more micro-processors or other control 
devices. 

In addition, those skilled in the art will appreciate that the present invention may be 
10 practiced in any number of data communication contacts and that the authorization 
system described herein is merely one exemplary application for the invention. Further, 
it should be noted that the present Invention may employ any nunnber of conventional 
techniques for data transmission, training, signal processing and conditioning, and the 
like. Such general techniques that may be known to those skilled In the art are not 
15 described in detail herein. 
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CLAIMS 

1 A system for authorizing commercial transactions comprising: 

a transaction card having an n character account code and an n character 
•.entifcation code, wherein said identification code is not an expiration ^^^e -d ^here^^^ 
5 a account code and said identification code have a predetermined .og.cal re.at.onsh.p. 
' ^ninputdeviceforreceivingsaidaccountcodeandsaididentificationcode; 

an authonzation computer in communication with said input device, said 
authorization computer configured to confim. said predetermined re.atipnship between 
1 0 said account code and said, identification code. 

2. The system of claim 1 . wherein said transaction card is at least one of a 
credit card, debit card, bank card, charge card and smart card. 

3. The system of claim 1 . where in said identification code is unembossed. 

4. The system of claim 1 . wherein said account code and said identification 
1 5 code are on the same side of said transaction card. 

5. Thesystemofclaiml.whereinsaidinputdeviceisatleastoneofakeypad. 
POS terminal. ATM terminal, computer and telephone. 

6. The system of claim 1 . wherein said identification code is at least one of a 
th-Tee^iigit-numberrfour^digit number and five-digit number. 

7 The system of claim 1 . wherein said account code and said identification 
code are on the same side of said transaction card and said identification code is an 
ur^embossed four-digit number located above said account code. - 
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8. The system of claim 1 . wherein said authorization connputer is configured 
to transform said identification code to a second identification code. 

9. The system of claim 1 , wherein said authorization computer communicates 
with an account database and said authorization computer is configured to confirm said 

5 predetermined relationship between said account code and said identification code by 
interrogation of said account database. 

1 0. A method for authorizing commercial transactions comprising: 

keying an n character account code and an n character identification code 
into an input device, wherein said identification code is not an expiration date and wherein 
10 said account code and said identification code have a predetemiined logical relationship; 

communicating, from said input device to an authorization computer, said 

account code and said identification code; and. 

confirming, at said authorization computer, said predetermined 
relationship between said account code and said identification code. 



15 



11. The method of claim 1 0. wherein said keying step includes keying said n 
character account code and said n character identification code into said input device, 
wherein said input device is at least one of a keypad. POS terminal. ATM terminal, 
computer and telephone. 

12. The method of claim 10. wherein said keying step includes keying said 
20 account code and said identification code which are located on a transaction card, further 

wherein said account code and said identification code are printed on the same side of 
said transaction card and said identification code is an unembossed four-digit number 
located above said account code. 

13. The method of claim 10. further comprising- transforming, via ,said 
25 authorization computer, said identification code to a second identification code. 
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14 The method of claim 10. further comprising communicating between said 
authorization computer and an account database and confirming, via said authorization 
computer, said predetermined relationship between said account code and sa.d 
identification code by interrogating said account database. 

5 1 5. A transaction card for authorizing commercial transactions comprising: 

an n character account code in a first field; 

an n character identification code in a second field, wherein said 

identification code is not an expiration date; 

wherein said account code and said identification code have a 

10 predetermined logical relatipnship: 

said transaction card configured to provide, via an input device, said account 
code and said identification code to an authorization computer, wherein said authorization 
computer is configured to confim. said predetermined relationship between said account 
code and said identification code. 

15 16. The system of claim 15. wherein said transaction card is at least one of a 

credit card, debit card, bank card, charge card and smart card. 

1 7 The system of claim 1 5. wherein said account code and said identification 
code are on the same side of said transaction card and said identification code is an 
unembossed four-digit number located above said account code. 
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